Search for: All records

The Domain Name System (DNS) leverages nearly 1K dis- tributed servers to provide information about the root of the Internet’s namespace. The large size and broad distri- bution of the root nameserver infrastructure has a number of benefits, including providing robustness, low delays to topologically close root servers and a way to cope with the immense torrent of queries destined for the root nameservers. While the root nameserver service operates well, it repre- sents a large community investment. Due to this large cost, in this paper we take the position that DNS’ root nameserv- ers should be eliminated. Instead, recursive resolvers should use a local copy of the root zone file instead of consulting root nameservers. This paper considers the pros and cons of this alternate approach. 

The advent of ultrabroadband Internet connectivity brings a 2-3 orders of magnitude jump in the capacity of access networks (a.k.a. the “last mile”). Beyond mere capacity increase, this leap represents a qualitative shift in the overall Internet environment. Therefore, we argue that only by seizing the opportunity to re-think the way we structure network applications and services can we realize the full potential ultrabroadband provides. Specifically, with ultrabroadband residential networks, we have the opportunity to re-center our digital lives around our residence, similar to how our physical lives generally center around our homes. To this end, we introduce a new appliance in home networks–a “home point of presence”–that provides a variety of services to the users in the house regardless of where they are physically located and connected to the network. We illustrate the utility of this appliance by discussing a range of new services that both bring new functionality to the users and improve performance of existing applications. 

Authoritative DNS servers are susceptible to being leveraged in denial of service attacks in which the attacker sends DNS queries while masquerading as a victim---and hence causing the DNS server to send the responses to the victim. This reflection off innocent DNS servers hides the attackers identity and often allows the attackers to amplify their traffic by employing small requests to elicit large responses. Several challenge-response techniques have been proposed to establish a requester's identity before sending a full answer. However, none of these are practical in that they do not work in the face of ``resolver pools''---or groups of DNS resolvers that work in concert to lookup records in the DNS. In these cases a challenge transmitted to some resolver $R_1$ may be handled by a resolver $R_2$, hence leaving an authoritative DNS server wondering whether $R_2$ is in fact another resolver in the pool or a victim. We offer a practical challenge-response mechanism that uses challenge chains to establish identity in the face of resolver pools. We illustrate that the practical cost of our scheme in terms of added delay is small.